\chapter{Tools and Framework} \label{chap:tools}
In this chapter the API used to communicate with StarCraft will be explained, as well as a library that extends the API called BWSAL. The architecture for the AI in this work will also be presented, which contains a modular case-based reasoning (CBR) framework and that the Micromanagement AI plugs into.

\section{BWAPI} \label{sec:bwapi}
Brood War Application Programmable Interface (BWAPI) \footnote{http://code.google.com/p/bwapi} is the API that is going to be used for controlling and getting information from StarCraft: Brood War. This is the API that the StarCraft AI competitions are based on \footnote{AIIDE acquired a content-use license from Blizzard to host the competition in 08.2011}. It was also the basis in the authors' Specialization Project where the research was centred around the use and possibilities of BWAPI. The API is written in and for C++, however there exists wrappers for several languages like Java and Python. Once compiled the DLL (Dynamic-link library) is injected by launching StarCraft using the third-party program Chaoslauncher \footnote{http://wiki.teamliquid.net/starcraft/Chaoslauncher}.

BWAPI gives complete access to the game states and control over all units and buildings, as well as lookup information about different static game properties. To exemplify what unit information of high importance BWAPI provides; the current hit points (HP), position coordinates, cooldown (for the next attack), attack strength as well as a myriad of unit-type specific information. These are also examples of the type of information that will be exploited in the AI that this report presents, and will be further explored in Chapter~\ref{chap:model}. 

\section{BWSAL} \label{sec:BWSAL}
The Brood War Standard Add-on Library (BWSAL) is a library for BWAPI that provides several useful features. Among these are automating building placement, scouting and additional unit information.

While the features provided by BWSAL is mainly of interest for AIs more versatile than one only focusing on Micromanagement, the \textit{UnitGroup} and the \textit{UnitGroupManager} classes will prove useful. They provides additional information about the position of the AI's units, as well as relevant topological positions like choke points. 

There are no alternative language wrappers available for BWSAL, which means that any project using it needs to be written in C++. 

\section{Architecture} \label{sec:architecture}
The architecture for the AI bot is based on the research done by the authors and several other students during a collaborative Specialization Project. The architecture behind the AI is structured as a module that can be plugged into a Case Based Reasoning (CBR) oriented agent architecture that is developed in parallel by a group of colleagues in connection with their thesis. The focus of the CBR agent is around Macromanagement, and the Micromanagement AI in this report will act as a plug-in that is activated as a reactive part of the system. The top-level architecture for this system is showed in Figure~\ref{fig:architecture}, and will be further explained in the following paragraphs.

\begin{figure}[h!]
	\includegraphics[width=12cm]{img/overview}
	\caption{The three layered architecture.}
	\label{fig:architecture}
\end{figure}

The architecture is based on a layered architecture used in robotics. It has three layers, where the top one is the Planning layer, the second one is the Executive layer and the third is the Reactive layer. The Planning layer makes plans, and alters them as new information is gained. 

The Executive layer will be responsible for resource management, deciding how to execute plans and in which order to do so. It passes the plans down to the reactive layer. The commands passed are composed of keywords like ``Attack'' and ``Enemy base''.

The Reactive Layer executes its orders by initializing new \textit{Behaviours}. Behaviours are given specific unit groups or buildings that is theirs to supervise and control. A Micromanagement AI will act as a \textit{Simple Behaviour} in this system as shown in Figure~\ref{fig:reactive}, instantiation will come from the Reactive layer once it senses a combat situation. When instanced the Micromanagement Behaviour will be delegated control over the units that needs to be Micromanaged. 

A behaviour is able to communicate its success with the Executive layer, and through that the Planning layer, with a simple communication protocol. A behaviour is usually initialized with a specific order like ``Attack Enemy Base X''. After this order is complete, or if the execution of this order fails, the behaviour reports back before terminating. In the case of the Micromanagement AI the order is to destroy the target within range of the group of units. If the enemy units are destroyed a ``Success'' is returned. If all the friendly units in the group dies then ``Failed'' is returned. Behaviours will live until either the behaviour itself says that it is done, or it is prematurely killed. Killing the Micromanagement behaviour may happen if the Executive layer finds that the unit group is of more use somewhere else or it predicts that the group will loose the combat engagement and should escape instead. The Micromanagement AI makes no such predictions, and will thus continue its behaviour until either all the units in its possession are dead, or the enemy units are.

\begin{figure}[H]
	\includegraphics[width=12cm]{img/reactive}
	\caption{The Reactive layer.}
	\label{fig:reactive}
\end{figure}

In addition to the mentioned layers the architecture has the Global Store and the Communication Module. The Global Store works as a collective memory and is similar to a Black Board. It keeps updated information on the game state as well as variables used. An example is that if new information comes to light all parts of the architecture gets to know it at once and can change their behaviour accordingly. The Communication Module handles the communication between layers in a simplistic but consistent way and is what is used for the API as discussed in the previous paragraph. Having the Communication Module lets the different layers be independent of each other, as they do not need information about where the messages comes from or goes to. 

The Micromanagement AI as a Simple Behaviour in relation to the system architecture is depicted in Figure~\ref{fig:micro_architecture}. The inner workings of the Micromanagement AI will be further detailed in the next chapter.

\begin{figure}[h]
	\includegraphics[width=\linewidth]{img/our_architecture}
	\caption[Micromanagement AI architecture]{Architectural view of the Micromanagement AI implemented as a Simple Behaviour.}
	\label{fig:micro_architecture}
\end{figure}

\todo{Better figure explained the relation between micro- and macromanagement.}